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1 . INTRODUCTION 


In  order  to  understand  the  CFA  final  selection  process,  it  is  first 
necessary  to  examine  how  the  general  goals  of  the  entire  program  were  em- 
bodied in  the  approach  taken  to  the  final  selection.  The  stated  puroose 
of  the  CFA  program  was  to  select  a single  computer  architecture  as  a 
standard  for  the  Army  and  Navy  and  then  implement  a family  of  upward  com- 
patible machines  based  on  that  architecture  to  meet  specific  cost/per- 
formance needs  of  various  military  applications.  By  pursuing  such  a pro- 
gram, the  Army  and  Navy  would  ultimately  benefit  in  terms  of  reduced  soft- 
ware costs  through  the  use  of  a common  base  for  software  development  and 
the  ability  to  apply  new  technology  to  gain  cost/performance  improvements. 
The  basis  for  selecting  an  architecture  for  consideration  as  an  Army/Navy 
standard  was  that  it  be  a current,  well  used,  understood,  supported  and 
documented  commercial  or  military  architecture.  The  underlying  assumption 
was  that  the  most  important  facet  of  an  architecture  was  its  general 
usability  and  support  base  given  that  it  meets  certain  technical  criteria. 

In  light  of  these  general  goals,  a choice  of  any  one  of  the  three 
finalists  would  have  been  satisfactory.  The  CFA  final  selection  process, 
however,  also  attempted  to  determine  which  one  of  the  three  finalists, 
if  selected,  would  be  the  most  cost  effective  for  the  military.  The 
Committee's  problem  was,  therefore,  not  to  determine  which  of  the  finalists 
was  "best"  in  absolute  terms  assuming  all  possible  computing  environments, 
but  rather  to  measure  the  military  data-processing  environment  and  then  to 
determine  the  candidate  that  would  fit  it  best. 

The  first  task  of  the  final  selection  process  was  gathering  informa- 
tion about  the  final  candidates,  and  military  computing  needs.  To  ac- 
complish this  task,  four  subcommittees  were  established  to  examine 
architectural -performance  parameters,  licensing  arrangements,  software 
bases,  and  life-cycle  costs  over  the  projected  life  of  the  probject. 

The  final  selection  process  was  divided  into  four  phases: 

a.  Data  Review.  Data  developed  by  the  Committee  in  connection 
with  initial  absolute/quantitative  criteria,  architecture  test 
results,  support  software  evaluation,  licensing  terms/conditions 
and  life  cycle  cost  analyses  were  reviewed  and  summarized. 

b.  Manufacturers'  Presentation.  Representatives  of  each  finalist 
were  invited  to  give  brief  presentations  about  future  plans  for 
their  architecture.  Questions  from  the  Committee  probed  areas  of 
concern. 
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c.  Discussion.  The  discussions  centered  around  contributing 
factors,  both  pro  and  con,  to  the  selection  of  each  architecture. 


d.  Summation.  Each  Architecture  Subcommittee  chairman  provided 
a summation  of  the  case  for  selection  of  his  architecture. 

e.  Recommendations.  This  report  considers  each  of  these  phases 
in  the  next  four  sections.  The  final  section  outlines  the  vote 
and  recommendations  of  the  Committee. 


2.  DATA  REVIEW 


a.  Overview 


The  data  developed  by  the  Committee  were  summarized  and  presented  as 
shown  in  Tables  1 and  2 for  the  absolute/quantitative  criteria  (used  to 
screen  out  three  CFA  finalists  from  a list  of  nine  candidates)  and  for  the 
above-described  other  data,  respectively.  Each  of  the  items  in  Tables  1 
and  2 is  discussed  below  in  the  following  subparagraphs. 


b.  Absolute/Quantitative  Criteria 


In  order  to  select  three  CFA  finalists  from  the  list  of  nine  candi- 
date CFA's,  the  Committee  established  a set  of  absolute  and  quantitative 
criteria  for  ranking  the  CFA  candidates.  Data  on  each  candidate  CFA  were 
provided  by  an  architecture  subcommittee  and  were  audited  to  ensure  equi- 
table architecture  evaluation.  Summary  results  are  shown  in  Table  1 
wherein  the  CFA  candidates  are  listed  in  the  order  of  their  ranking  by 
the  quantitative  criteria  with  remarks  concerning  their  absolute  criteria 
evaluation.  As  a result  of  this  screening  process,  three  CFA  finalists 
were  selected  for  further  evaluation;  Interdata  8/32,  DEC  PDP-11,  and 
IBM  S/370. 


c.  Architectural  Test  Results 


One  of  the  major  questions  raised  during  the  selection  process  was 
the  relative  capabilities  of  the  finalists  in  implementing  characteristic 
problem  solutions.  If  tests  inaicated  that  one  architecture  needed 
significantly  less  memory  and  processing  power  to  execute  a task,  it 
would  be  possible  to  say  that  the  hardware  costs  associated  with  imple- 
menting that  architecture  would  be  less  than  for  the  others.  The  approach 
taken  to  answer  this  question  was  to  describe  the  programming  level  of 
each  of  the  finalists  using  the  ISP  notation.  A simulator  for  each 
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ARCHITECTURE 

QUANTITATIVE 

CRITERIA 

ABSOLUTE 

CRITERIA 

INTERDATA  8/32 

1.68  (BEST) 

Problem  with  interrupts  and  traps 

PDP-11 

1.43 

Passed  all 

IBM  S/370 

1.36 

Passed  all 

AN/GYK-12 

.94 

Failed  floating  point 

ROLM/NOVA 

.92 

Failed  virtual  memory  mapping  and 
interrupts/traps 

B6700 

.91 

Failed  protection 

SEL-32 

.86 

Failed  virtual  memory  mapping 

AN/UYK-7 

.46 

Failed  floating  point 

AN/UYK 

.44  (WORST) 

Failed  protection 

Table  1.  CFA  Candidate  Scores  on  Absolute  and  Quantitative  Criteria 


QUANTITATIVE  CRITERIA  TEST  PROGRAM  RESULTS 

SCORES  RMS 


8/32 

1 .68 

.83 

.85 

,83 

PDP-11 

1 .43 

.94 

.93 

1 .00 

S/370 

1.36 

1 .29 

1 .27 

1 .21 

SEE  NOTE  1 BELOW 

SEE 

NOTE  2 BELOW 

SUPPORr SOFTWARE  VALUE 
CURRENTLY 

AVAILABLE  DEFICIENCY 


8/32 

$15. 3M 

$25. 9M 

PDP-11 

$22. 2M 

$19. IM 

S/370 

$32. 3M 

$ 9.6M 

TOP  DOWN 
RELATIVE 

COST  MODEL 
COST  (S/370 

(SEE  NOTE  3) 

= 1) 

BOTTOM  UP  COST 
RELATIVE 

COST  (S/370  = 

MODEL  FOR  1985 
#SYSTEMS  PREF. 
1)  (SEE  NOTE  4) 

8/32 

1.23 

1 .00 

— 

PDP-11 

1.07 

.91 

14.5 

S/370 

1.00 

1 .09 

0.5 

NOTE  1 : These  are  relative  values  with  an  average  value  of  one  for  nine  CFA 
candidates.  The  higher  the  value,  the  better  the  architecture. 

NOTE  2:  These  are  relative  values  with  an  average  value  of  one  for  the  three 
CFA  finalists.  The  lower  the  value,  the  better  the  architecture.  S is  a 
measure  of  the  program  storage  required  for  test  programs  by  each  architec- 
ture. M is  a measure  of  the  processor/memory  bandwidth  to  run  the  test  pro- 
grams, i.e.  # bytes  transferred  between  processor  and  memory.  R is  a mea- 
sure of  the  internal  processor  bandwidth  required  to  run  the  test  programs. 

NOTE  3;  Top  down  cost  model  analyzed  variation  of  DOD  computer  resource 
budqet  as  a function  of  the  selected  CFA. 


NOTE  4:  Bottom  up  cost  model  analyzed  variation  of  life  cycle  cost  of  15 
I tactical  data  systems  as  a function  of  the  selected  CFA.  Relative  cost 

i refers  to  total  life  cycle  cost  of  all  15  systems.  # Systems  preferred 

I indicates  the  number  of  systems  with  the  lowest  life  cycle  costs  for  each 

[ architecture.  The  ".5"  denotes  a tie  betwen  two  architectures  for  one 

! system. 

I 

I 

I Table  2.  Final  CFA  Selection  Data  Summary 
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architecture  was  then  obtained  by  compiling  each  description  on  the  ISP 
compiler  at  Carnegie-Mel Ion  University  (CMU)  in  Pittsburgh.  Test  programs 
representative  of  military  computing  tasks  were  then  run  on  these  simula- 
tors. In  order  to  characterize  each  machine's  performance  on  these  pro- 
grams, values  of  three  measures,  S,  M and  R,  were  collected.  These  measures 
can  be  roughly  defined  as  follows; 


S measure  - A count  of  the  number  of  bytes  needed  to  store  the 
instruction  stream  for  a test  program. 

M measure  - The  number  of  bytes  transferred  between  the  central 
processor  and  main  memory  during  the  execution  of  a 
test  program. 

R measure  - The  number  of  register  transfers,  both  internal  to  the 
central  processor  and  vi sable  to  the  programmer,  needed 
during  the  execution  of  the  test  program. 

The  generation  of  the  S,  M,  and  R values  for  each  architecture  was  con- 
trolled according  to  an  experimental  design  devised  at  CMU.  In  accordance 
with  this  design,  subsets  of  12  test  programs  were  assigned  to  18  pro- 
grammers both  at  CMU  and  Army/Navy  labs  and  aoDroximatel v ino  data  points  collected. 

The  results  of  the  benchmark  programming,  simulation,  and  statistical 
analysis  which  formed  the  architectural  test  were  presented  and  are  sum- 
marized in  Table  2.  The  physical  interpretation  given  to  these  results 
was  that,  on  the  average,  the  IBM  360/370  architecture  required  approxi- 
mately 20%  more  core  and  processing  power  than  the  PDP-11  and  40%  more 
than  the  Interdata  8/32  to  execute  the  test  program  set. 

A study  of  the  S,  M,  and  R measures  for  individual  benchmark  programs 
pinpointed  the  relative  weaknesses  of  each  architecture.  These  weaknesses 
should  be  considered  during  the  implementation  plan  of  the  Military  Com- 
puter Family  (MCF)  architecture.  In  particular,  the  Interdata  8/32  per- 
formed uniformly  well.  The  PDP-11  was  comparable  to  the  8/32  in  all 
benchmarks  except  the  two  that  required  large  address  spaces:  the  FFT 
and  Quicksort.  As  reflected  in  the  M measure,  the  PDP-11  typically 
took  two  to  three  times  as  many  memory  transactions  (e.g.,  15,000  to  9000 
bytes  for  the  FFT),  as  the  Interdata  8/32.  The  S/370  was  generally 
slightly  worse  than  the  other  candidates.  However,  a significant  dif- 
ference was  observed  on  the  I/O  benchmarks  where  the  S/370  was  a factor 
of  10-20  times  worse  than  either  the  Interdata  8/32  or  the  PDP-11  (e.g.,  an 
M measure  of  370  bytes  to  30  bytes  for  I/O  kernel). 

The  Architectural  Test  Failed  to  incorporate  two  factors  that  some 
committee  members  felt  important:  previous  programmer  experience  with 
the  architectures  (i.e.,  there  are  many  skilled  S/370  and  PDP-11  pro- 
grammers but  few  8/32  programmers),  and  the  relative  amount  of  program- 
ming time  required  for  each  benchmark  as  a function  of  architecture  (i.e., 
two  architectures  being  equal,  one  might  be  more  difficult  to  program  and 
require  more  time  to  produce  a program  of  equal  quality). 
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The  statistical  analysis  showed  that  at  the  95%  confidence  level 
(i.e.,  if  the  experiment  was  conducted  100  times,  95  of  those  times  the 
results  would  be  the  same)  the  Interdata  8/32  was  superior  to  the  S/370. 
The  PDP-11  was  superior  to  the  S/370  at  about  the  90%  confidence  level. 
At  the  95%  confidence  level,  the  Architectural  Test  did  not  uncover  any 
statistically  significant  difference  between  the  PDP-11  and  the  Inter- 
data 8/32.  Since  the  Interdata  8/32  and  PDP-11  were  closely  matched, 
the  average  of  their  values  v s used  and  shown  to  be  superior  to  the 
S/370  at  the  95%  confidence  level. 


d.  Support  Software  Evaluation 


Another  facet  of  each  architecture  considered  significant  to  the 
evaluation  process  was  the  value  of  their  respective  software  bases.  Con- 
sideration of  this  factor  was  based  on  the  notion  that  the  more  complete 
an  architecture's  software  base  was,  the  less  the  investment  required  by 
the  military  in  that  base  and  the  more  immediately  useful  the  architec- 
ture. The  approach  taken  was  to  consider  the  software  base  as  a set  of 
tools  for  use  in  developing  applications  programs.  Included  in  this  set 
were  nnt  nniy  editors,  linkers,  compilers,  and  such,  but  also  high  level 
DaLd  Base  Management  Systems,  library  packages  and  a number  of  different 
types  of  operating  systems.  This  set,  as  a whole,  was  then  presented  to 
each  member  of  the  committee  with  the  request  that  he  rank  them  in  accord- 
ance with  their  significance  to  his  typical  applications. 

The  results  of  the  support  software  evaluation  are  summarized  in 
Table  2.  The  value  of  the  currently  available  support  software  base  (in 
terms  of  the  cost  to  develop  it  today)  is  shown  in  the  lefthand  column 
for  the  three  CFA  finalists.  The  support  software  base  of  each  CFA 
finalist  was  compared  with  the  desired  software  base  as  determined  by 
committee  vote.  The  value  of  the  deficiency  in  millions  of  dollars  is 
tablulated  in  the  righthand  column  of  Table  2.  The  result  of  the  study 
was  that  existing  support  software  base  was  greatest  for  the  IBM  S/370 
and  least  for  the  Interdata  8/32.  This  result  implied  that  if  the  IBM 
S/370  architecture  were  selected,  then  the  needed  investment  in  software 
tools  would  be  less  than  for  the  other  two  architectures. 


e.  CFA  Licensing  Terms/Conditions 


A somewhat  difficult  to  quantify,  but,  nevertheless,  very  important 
issue  was  the  wil lingness  of  every  manufacturer  to  cooperate  with  the 
government,  assuming  his  architecture  was  selected.  While  not  a strictly 
technical  issue,  the  undesirability  of  recommending  an  architecture  of  an 
unwilling  manufacturer  was  recognized  by  the  committee.  In  order  to  ad- 
dress this  issue,  a series  of  meetings  were  held  with  each  manufacturer 
by  selected  representatives  of  the  Army  and  Navy  to  inquire  as  to  what 
the  manufacturers  might  expect  in  return  for  the  use  of  their  architecture 
by  the  government,  e.g.,  what  kind  of  licensing  agreement  they  would  re- 
quire. The  results  of  these  meetings  indicated,  both  through  each  man- 
ufacturer's licensing  requirements  and  their  attitude  during  the  meetings, 
that  all  three  manufacturers  were  willing  to  cooperate,  but  that  DEC 
showed  the  most  interest  and  responsiveness.  The  details  of  the  proposed 

6 


licensing  agreements  are  given  in  Volume  VII. 


f.  Life  Cycle  Cost  Models  <• 


Although  the  above  described  information,  along  with  the  qualitative 
and  quantitative  criteria  formed  a sizeable  data  base  on  the  CFA  finalists, 
the  actual  impact  of  selecting  any  one  of  them  on  the  military  computing 
environment  was  unclear.  The  basic  cause  of  this  situation  was  the  lack 
of  a quantitative  method  to  relate  all  of  the  above  information  (such  as 
S,  M and  R measures)  to  the  relative  dollar  cost  to  the  Army  and  Navy  of 
using  a particular  architecture.  Without  such  a method,  the  selection 
of  an  architecture  by  the  CFA  committee  might  be  difficult  to  justify  to 
upper  level  DoD  management.  Recognizing  this  possibility,  the  committee 
determined  to  compare  the  CFA  finalists  on  a life-cycle  cost  basis. 

The  life  cycle  cost  analyses  used  two  independently  developed  and 
distinct  models  of  military  computer  resource  requirements:  the  "^op  Down 
Model  and  the  Bottom  Up  Model . 


(1)  Top  Down  Life  Cycle  Cost  Analysis 


The  top  down  model  involved  calculating  the  relative  cummulative  cost 
incurred  by  each  architecture  over  a time  period  of  one  to  thirteen  years 
beginning  in  1978.  The  model  used  as  inputs  not  only  data  gathered  by 
the  CFA  subcommittees  but  also  projections  of  trends  in  overall  military 
requirements  and  dollar  expenditures  for  both  hardware  and  software, 
estimates  of  the  impact  of  the  available  support  software  on  software 
production  costs,  and  estimates  of  the  relative  amounts  spent  on  processors 
and  memories.  The  model  also  considered  the  time  value  of  money  and 
architecture  related  parameters.  The  best  architecture  for  a time 
period  would  be  the  one  that  produced  the  lowest  relative  cummulative 
cost  over  the  development  cycle.  The  relative  life  cycle  costs  are 
shown  in  Table  2 for  the  conditions  where  the  hardware-to-software 
cost  ratio  is  1:1  in  1985  and  the  estimated  support- software  investment 
for  the  selected  CFA  from  1978  on  is  $2M  annually.  Table  2 indicated 
that  the  1935  relative  life  cycle  costs  of  PDP-11  and  S/370  are  comparable 
and  approximately  20%  less  than  the  8/32  cost. 


(2)  Bottom  Up  Life  Cycle  Cost  Analysis 


The  major  difference  between  the  second,  or  bottom  up,  model  and 
the  top  down  model  lies  in  the  data  used  for  inputs.  Whereas  the  top 
down  model  used  estimates  and  projections  of  trends  in  military  computing 
requirements  and  expenditures,  the  bottom  up  model  attempted  to  use  a 
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number  of  current  military  computing  applications  as  representative  ex-  i 

amples  of  future  requirements.  Fifteen  Army  embedded  computer  systems  J 

ranging  in  size  from  small  fire-control  to  large  data-base  management  I 

systems  were  used  as  the  basis  for  the  Bottom  Up  model.  Each  system  j 

was  characterized  in  terms  of  memory  and  secondary  storage  requirements, 
processor  power,  number  of  installations,  and  various  other  system  ' 

parameters.  The  data  were  then  combined  in  the  model  with  certain  * 

architectural  parameters  in  order  to  determine  which  architecture 

would  be  most  cost  effective  for  each  system.  The  total  life  cycle  cost  | 

for  each  system  and  for  all  15  systems  was  estimated  for  1976  and  1985  • 

procurements.  Table  2 indicates  the  relative  total  cost  and  the  number 
of  systems  for  which  each  architecture  provided  the  lowest  life  cycle 
cost.  Table  2 is  based  upon  the  conditions  where  the  average  applica-  . \ 

tions  software  cost  per  instruction  in  1976  is  S34  (corresponding  to  a j 

hardware-to-software  ratio  of  1.2:1  in  1985)  and  the  estimated  support  : 

software  investment  for  the  selected  CFA  from  1976  on  is  $2M  annually. 

Table  2 indicates  that  the  PDP-11  had  the  lowest  total  cost  by  approxi- 
mately 13"  and  the  largest  number  of  system  preferences  on  the  basis  of  j 

individual  system  life  cycle  cost.  j 

Limited  sensitivity  analyses  of  both  life  cycle  cost  models  were  I 

made  with  respect  to  hardware-to-software  ratio,  support  software  annual  [! 

investment  and  whether  or  not  weighting  was  applied  to  the  architecture 
test  measures  S,  M,  and  R.  The  comparative  life  cycle  costs  of  the  three 
architectures  were  examined  over  a range  of  parameters:  1985  hardware- 
to-software  ratios  of  1:1  to  2:1;  annual  support  software  investment  of 
SIM,  S2M  and  $3M;  weighted  or  unweighted  architecture  test  measures  in 
the  bottom  up  model;  and  1976  to  1985  hardware  cost  ratio  of  10:1  and 


In  othi r words,  the  8/32  looked  like  a good  choice  and  the  S/370 
looked  like  u poor  choice  with  assumptions  which  maximize  the  cost  of 
hardware,  and  minimize  the  cost  of  software,  while  the  S/370  looked  like 
a good  choice  and  the  8/32  looked  like  a poor  choice  under  those  assump- 
tions which  maximized  the  importance  of  software  costs.  The  PDP-11, 
however,  looked  like  a good  choice  in  the  mid  range  of  assumptions  and 
neither  best  nor  worst  in  the  extremes.  Given  the  uncertainties  of 
the  input  data  and  assumptions,  the  results  of  the  two  models  appeared 
to  agree  reasonably  well,  and  the  relative  closeness  of  the  three  archi- 
tectures indicated  that  all  three  would  be  comparable  choices  in  terms 
of  1 i fe  cycle  cost. 


3.  MANUFACTURERS'  PRESENTATION 


I Each  manufacturer  of  a CFA  finalist  was  invited  to  give  a talk  on 

the  future  plans  for  their  architecture.  Since  the  manufacturers  did 
not  hear  each  other's  presentations,  the  results  are  not  comparable. 
However,  a number  of  interesting  issues  were  raised  that  contributed  to  the 
final  selection.  The  presentations  are  summarized  below. 
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a.  DEC 


The  PDP-11  family  currently  comprises  13  processor  models  spanninq  a cost  ranqe 
greater  than  100:1.  this  exemplifies  the  implementation  versatility  ot  tne 
PDP-11  as  well  as  DEC'S  commitment  to  perpetuating  the  architecture.  New  pro- 
duct announcements  include  a Commercial  Instruction  Set  (CIS),  a Program 
Logical  Address  Space  (PLA5),  and  DECnet.  PLAS  is  a software  system  that 
automatically  manages  address  mapping  registers  for  user  subroutines  in 
an  attempt  to  make  the  16-bit  address  space  appear  as  large  as  24  bits. 

DECnet  is  a network  protocol  and  associated  software  that  allows  different 
DEC  operating  systems,  perhaps  running  on  totally  different  architectures 
(e.g.,  PDP-10,  PDP-11,  PDP-8),  to  communicate. 

DEC  has  traditionally  been  noted  for  supplying  interfacing  informa- 
tion and  documentation  to  users.  This  practice  should  be  helpful  for 
designers  of  military  embedded-computer  systems. 

Two  areas  of  concern  were  explored  by  the  committee  during  the  ques- 
tion and  answer  period.  The  first  was  Floating  Point  Instruction  Sets 
(FPIS).  The  PDP-11  family  ^as  two  different  FPIS:  a four  instruction 
set  that  takes  its  operands  from  the  stack  and  is  implemented  in  low  end 
PDP-11 's,  and  a full  FPIS  that  is  incorporated  in  a special  floating- 
point processor,  complete  with  single  and  double  precision  floating- 
point registers.  The  high-end  PDP-11 's  have  the  full  FPIS  but  do  not 
implement  the  four  instruction  set  in  hardware  (they  could  be  handled 
in  software  via  unimplemented  instruction  traps).  DEC  has  not  felt 
market  pressure  to  make  both  FPIS's  available  in  high  level  machines. 

If  the  PDP-11  is  selected,  the  two  FPIS  problems  should  be  considered 
in  the  MCF  implementation  plan. 

The  second  concern  was  the  small  16-bit  physical  address  space  in  the 
PDP-11.  DEC  would  only  assure  us  that  a solution  to  the  limited  address 
space  problem  would  be  marketed  before  the  end  of  the  decade.  Again, 
this  topic  should  be  pursued  in  careful  detail  in  any  MCF  implementation 
plan.  On  the  whole,  DEC  seemed  eager  to  cooperate  and  have  their  archi- 
tecture selected. 


b.  IBM 


Two  interesting  comments  were  made  by  IBM.  The  first  was  in  effect, 
"We  are  not  here  to  encourage  or  discourage  the  selection  of  the  S/370." 
This  eventually  led  to  some  concern  by  the  committee  about  IBM's  eventual 
cooperativeness  and  helpfulness  if  the  S/370  were  selected.  The  other 
comment  concerned  the  level  of  standardization  IBM  will  maintain  across 
future  models  of  the  S/370.  Basically,  IBM  is  committed  to  holding  the 
machine  as  seen  by  nonprivileged  programs  (e.g.,  problem  state)  invariant. 
Changes  can  be  made  to  anything  below  the  user  interface  with  the  operating 
system  (OS).  The  manner  in  which  portions  of  the  OS  are  implemented, 
whether  in  software,  firmware  (microcode),  or  hardware,  is  open  to  future 
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change.  In  particular,  the  I/O  architecture  is  not  guaranteed  to  remain 
invariant.  This  posed  an  interesting  dilemma  for  selection  of  the  S/370 
as  the  MCF  CFA.  The  selection  committee  had  decided  to  standardize  on 
the  instruction-set  architecture  and  not  the  problem  state  architecture. 

If  the  S/370  were  selected  and  its  instruction-set  architecture  implemented, 
a risk  would  be  run  that,  in  the  future,  IBM  might  diverge.  The  MCF  might 
not  be  able  to  capitalize  on  future  IBM  software.  Furthermore,  as  IBM 
phased  out  support  of  its  old  software  (since  the  instruction  set  was  not 
the  same  as  new  IBM  architectures)  DOD  would  have  to  take  over  its  main- 
tenance and  improvement. 

In  addition,  if  the  S/370  were  selected  and  the  problem  state  architec- 
ture standardized  on,  another  problem  arises.  In  order  to  operate,  the 
problem  state  needs  run-time  support  from  the  OS,  particularly  in  the  area 
of  I/O.  IBM  estimated  that  run-time  support  would  be  at  least  5K  of  in- 
structions. Further,  any  given  I/O  request  would  require  the  execution 
of  about  1200  to  3600  instructions  (at  1 microsecond/instruction  that 
means  an  I/O  interrupt  response  time  on  the  order  of  1-4  milliseconds). 

Not  only  would  I/O  response  time  be  slow,  but  small  tactical  applications 
would  have  to  carry  along  an  extra  5K  of  memory  for  run-time  support.  Of 
course,  solutions  can  be  found,  but  the  tactical  MCF  would  no  longer  be 
compatible  with  the  S/370. 


c.  Interdata 


Interdata's  presentation  was  primarily  a review  of  the  technology 
used  in  the  8/32  system.  A floating  point  box  has  been  delivered  for  an  8/32. 
They  stated  that  they  did  not  feel  that  technology  was  here  yet  to  implement 
an  LSI  version  of  the  8/32.  This  comment  leads  to  some  concern  about  the 
applicability  and  cost  effectiveness  of  the  8/32  architecture  in  small 
^actical -systems . 


4.  DISCUSSION 


■’■'•■.'c  global  concerns  were  expressed  that  apply  to  all  architectures: 
lamily  planning  and  virtual  machines.  The  following  sections  treat  these 
issues  first  and  then  give  other  comments  grouped  by  machine. 


a.  Family 


By  careful  family  planning,  IBM  has  attempted  to  insure  the  transport- 
ability of  user  programs  between  machine  models.  While  not  100%  successful 
in  this  goal,  IBM  has  over  15  years  of  experience  and  has  come  closer  to  the 
transportability  goal  than  any  other  manufacturer. 


in 


A 


DEC  has  built  a family  of  PDP-11 's,  but  there  are  know  incompatibilities 
in  the  instruction  sets.  Certain  instructions  execute  differently  on  differ- 
ent machines.  If  there  is  no  canonical  PDP-11,  then  all  the  software  may 
not  be  transportable  throughout  the  MCF.  Family  consistency  requires  care- 
ful planning  (IBM  has  a full-time  staff  of  12  professionals  whose  sole  job 
is  to  insure  family  consistency). 

The  Interdata  8/32  has  not  really  faced  the  problem  of  family  planning. 
There  is  a 16-bit  version  of  the  8/32,  but  compatibility  is  enforced  at  the 
assembly  language  level  and  a program  must  be  reassembled  to  run  on  the  other 
machine. 


b.  Virtual  Machines  (VM) 


Some  members  of  the  committee  felt  that  it  was  essential  that  the  MCF 
support  virtual  machines.  A VM  system  gives  each  user  what  appears  to  be  a 
complete,  independent  machine,  and  permits  different  applications  programs 
running  under  different  operating  systems  to  co-exist  on  the  same  physical 
hardware.  Some  concern  was  expressed  about  the  applicability  of  VM's  in 
tactical  situitions  due  to  the  VM  overhead. 

IBM  has  delivered  a VM  system.  Although  DEC  has  a hardware  option  that 
makes  the  PDP-11  virtual izable,  DEC  has  not  developed  any  software  support 
of  a VM.  Interdata  has  not  considered  the  problem. 


c.  DEC  PDP-11 


Concern  continued  to  be  expressed  over  the  small  address  space  of  the 
PDP-11  and  its  ability  to  handle  large  problems.  It  was  pointed  out  that 
future  military  systems  will  be  distributed  and  that  large  address  spaces 
may  not  be  a problem.  It  was  also  noted  that  a substantial  amount  of  work 
on  distributed,  multiprocessor  systems  has  been  done  utilizing  the  PDP-11. 

In  any  event,  the  small  address  space  was  explicitly  tested  by  two  of  the 
test  programs.  Even  with  the  degradation  in  performance  on  these  programs, 
the  difference  between  the  PDP-11  and  the  8/32  was  not  statistically  signifi- 
cant at  the  95%  confidence  level.  The  PDP-11  has  good  I/O  characteristics 
and  was  originally  designed  for  the  small  applications  area. 


d.  IBM 


Poor  I/O  interrupt  response  remains  a key  issue  with  regard  to  the  S/370. 
The  test  programs  underline  this  deficiency.  Also,  it  is  unclear  whether 
the  I/O  structure  can  be  subsetted  in  a compatible  manner  for  tactical 
systems.  It  was  pointed  out  that  IBM  has  built  an  advanced  aerospace  com- 
puter of  small  size  and  weight  which  is  360  instruction-set  compatible  at 
the  problem  state  level. 
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IBM  let  it  be  known  that  it  would  not  provide  their  architectural  veri- 
fication programs  to  DOD.  However,  IBM  was  the  only  one  of  the  three  manu- 
factures which  had  developed  such  programs. 


e.  Interdata 


CFA  licensing  terms  dominated  the  concern  over  the  selection  of  the 
8/32.  (See  Volume  VII)  Concern  continued  over  the  support  software. 
Although  the  Interdata  was  shown  to  have  half  the  software  base  of  the 
S/370,  the  software  study  did  not  take  into  account  the  maturity  or 
diversity  of  the  software.  For  example,  a newly  released  Fortran  com- 
piler would  have  counted  equivalently  to  10  well  tested  compilers,  some 
of  which  might  produce  optimized  code,  while  others  might  have  fast  com- 
pilation times  for  program  development.  The  strong  showing  of  the  8/32 
in  the  test  program  results  and  its  efficient  I/O  characteristics  are 
indicative  of  the  fact  that  it  was  designed  for  control  and  communications 
appl ications. 


5.  SUMMATION 


The  issues  were  summarized  for  each  architecture  by  the  various  Archi- 
tectural Subcommittee  Chairmen. 


PDP-11 


‘^/370 


8/32 


Epx 

Large  implemented  range 
Experience  with  OEM  systems 
Experience  with  distributed 
systems 

Good  performance  on  1 i i e 
cycle  cost  models 
Good  interrupt  structure 
Cooperative  manufacturer 

Large  software  base 
Very  precise  definition  of 
the  architecture 
Virtual  Machine  Operating 
System  supported 

Most  efficient  on  test 
programs 

Architecture  with  room  for 
expansion 

Good  interrupt  structure 


Against 

Small  virtual  address 
space  problem 


I/O  interruot  resoonse 
Least  efficient  on  test 
programs 
Subsetabil ity 

Weak  support  software 

Weak  performance  on  life 
cycle  cost  model 
Licensing 

No  virtual  machine  capa- 
bility 
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6.  FINAL  SELECTION/RECOMMENDATIONS 


A vote  was  taken  for  the  third  place  architecture,  in  order  to  maximize 
the  possibility  of  getting  a two  thirds  majority  on  the  selection  of  the 
final  candidate.  The  vote  was: 

16  Interdata  8/32 
1 PDP-11 
1 not  present 

The  final  vote  for  best  architecture  was: 

14  PDP-11 
4 S/370. 

The  committee  had  foui^  final  recommendations: 

a.  The  committee  unanimously  agreed  that  a single  instruction-set 
architecture  should  be  selected  for  the  MCE,  that  the  selection  of 
only  one  architecture  is  more  important  than  which  one  of  the  tnree 
final  candidate  architectures  is  selected,  and  that  any  one  of  the 
three  could  provide  a satisfactory  basis  for  the  MCF. 

b.  The  DEC  PDP-11  was  determined  to  be  the  most  advantageous 
architecture  for  the  MCF,  the  IBM  S/370  was  ranked  second,  and  the 
Interdata  8/32  was  ranked  third. 

c.  The  committee  agreed  that  an  effort  should  be  made  to  correct 
the  limitations  of  the  selected  architecture. 

PDP-11:  Small  address  space 

Floating  point  instruction  compatibility 

S/370:  I/O 

Low  end  subsetabil ity 

Interdata  8/32:  Complete  study  of  interrupt/trap  recovery 
Virtualizability 

d.  A single  organizational  structure  must  be  established  to 
control  the  architecture,  otherwise  major  incompatabil ities 
between  different  implementations  will  surely  result. 

Also,  it  is  clear  that  the  military's  involvement  in  architectural  ques 
tions  cannot  end  with  the  CFA  final  selection.  If  architectural  control  is 
lost  at  any  time  during  the  life-cycle  of  the  CFA  project,  the  problems  the 
CFA  was  conceived  to  relieve  will  remain  and  the  results  will  be  little 
better  than  the  situation  that  exists  prior  to  CFA. 
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